抱歉,您的浏览器无法访问本站
本页面需要浏览器支持(启用)JavaScript
了解详情 >

最开始折腾 my-codex-os 的时候,我脑子里其实有一个很朴素、甚至有点中二的念头:能不能给自己做一个像《钢铁侠》里贾维斯那样的 AI 助手?

这个念头并不是凭空出现的。Codex CLI、Claude Code、Gemini CLI 这类能够在本地项目里协作的 AI 工具出现后,我第一次很强烈地感觉到:AI 不再只是网页里那个回答问题的聊天框,而是可以进入我的真实工作现场。

它可以读项目文件,可以修改代码,可以帮我整理材料,可以检查结构,可以在一个文件夹里理解上下文,然后继续往下做事。对我来说,这个变化非常重要。因为我几乎所有课程作业、工程项目、文章整理,都已经在不同程度上依赖 Codex 的大量协助。

于是我很自然地开始想:既然 AI 已经能进入本地工作区,那它能不能更进一步,成为一个长期陪我工作和学习的个人助手?

当时已经有一些项目在尝试把 AI 接入语音,用唤醒词、TTS、麦克风、摄像头之类的方式做出一个更像“智能管家”的界面。这当然很酷。但我慢慢发现,真正让我在意的并不是语音交互。

如果一个 AI 只是用更像人的声音叫我一声,但它不知道我是谁、不知道我现在在做什么、不知道哪些文件是 source of truth、不知道哪些事情必须先确认、不知道我的写作风格和隐私边界,那它离“懂我”其实还很远。

所以我真正想探索的问题变成了:

抛开语音,一个 AI 到底要具备什么,才算是一个真正“懂我”的助手?

my-codex-os 就是在这个问题下面长出来的一个个人系统。

它不是一个真正意义上的操作系统,也不是一个炫技式的 AI 外壳。更准确地说,它是我给 Codex 准备的一套个人协作环境:用一组 Markdown 文件、目录结构和 skills,把我的身份信息、工作原则、工具边界、长期记忆、当前关注和具体任务流程写成 AI 可以读取和执行的形式。

如果只用一句话概括:

my-codex-os 表面上是给 Codex 读的文件夹,实际上是我把自己的一部分工作方式、判断边界和长期偏好,蒸馏成 AI 可以调用的系统。

不是让 AI 更像人,而是让它更懂现场

我们很容易把“个人 AI 助手”想象成一个拟人化的东西:它会说话,会回应,会叫你的名字,甚至会有某种人格。

这些当然会影响体验。我自己也承认,一个助手如果有稳定的称呼、语气和协作风格,用起来会更顺手。但如果只停留在这里,个人助手很快就会变成一种表演。

真正重要的不是它像不像一个人,而是它能不能理解“现场”。

这个现场至少包括几件事:

  • 我是谁,我的背景和长期偏好是什么;
  • 我现在正在关注什么;
  • 哪些信息可以作为长期记忆,哪些只是临时上下文;
  • 哪些工具分别负责什么;
  • 哪些本地文件可以改,哪些不能乱碰;
  • 一个任务到底应该发生在哪个工作区;
  • 什么情况下 AI 可以直接执行,什么情况下必须先问我。

过去我们和 AI 协作,很多时候是靠一次性 prompt。每次打开一个新对话,都要重新介绍一遍自己,重新解释项目背景,重新告诉它“别乱编”“别改这个文件”“这个目录才是最终版本”。

这当然能用,但它不稳定,也很浪费注意力。

所以我后来越来越觉得:与其每次把上下文塞进 prompt,不如把一部分稳定上下文沉淀成系统。

这就是 my-codex-os 的基本出发点。

my-codex-os 大概长什么样

my-codex-os 的结构并不复杂。它更像一个给 AI 用的个人工作台,而不是一个大而全的软件系统。

一个简化后的结构大概是这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
my-codex-os/
├─ README.md
├─ AGENTS.md
├─ SKILLS/
│ ├─ assistant-presence/
│ ├─ memory-ops/
│ ├─ ticktick-ops/
│ ├─ siyuan-ops/
│ ├─ workspace-ops/
│ ├─ workspace-router/
│ └─ blogverse-ops/
└─ SYSTEM/
├─ AGENT_PROFILE.md
├─ AGENT_PROTOCOL.md
├─ WORKBENCH/
├─ MEMORY/
└─ SOURCES/

这里面最核心的不是目录名字,而是职责分层。

README.md 是入口卡,告诉 Codex 这个系统是什么、启动时应该先看什么。

AGENT_PROFILE.md 记录我是谁,例如我的背景、常用工具、默认沟通偏好、输出风格和一些长期协作边界。

AGENT_PROTOCOL.md 记录系统原则,例如滴答清单负责计划,思源笔记负责知识沉淀,本地文件只保存稳定画像、当前上下文、长期记忆和变更痕迹。

WORKBENCH/CONTEXT.md 是当前工作台,只放当前真正需要激活的上下文。它像桌面,不像档案馆。

MEMORY/ 用来放长期记忆,但不是所有聊过的话都应该进去。只有经过确认、以后可能反复调用、值得保留的事实、决策和术语,才适合沉淀。

SKILLS/ 则是给 Codex 的专项操作手册。不同任务有不同 skill:记忆怎么启动,任务怎么规划,思源怎么检索,博客文章怎么写,外部工作区怎么路由。

我现在越来越觉得,一个个人 AI 系统最重要的不是“功能很多”,而是“边界清楚”。

本地 Markdown 不是日程系统,任务应该交给滴答清单;知识沉淀不应该全堆在项目目录里,应该进思源或长期记忆;外部项目文件不应该为了方便复制一份到 my-codex-os,因为那会制造第二份 source of truth。

这些规则听起来有点克制,但正是这种克制,让 AI 不至于从助手变成噪音制造机。

一个 AI 想长期协作,至少要知道什么

如果你也想搭一个自己的个人 AI 工作系统,我觉得不必一开始就照抄我的目录。更好的方式,是先问一个问题:

如果一个 AI 明天开始长期协助我,它最应该稳定知道哪些事?

我的答案大概分成五类。

第一类是身份画像。

这不是让 AI 记住一堆隐私,而是让它知道与你协作时最基本的工作假设。比如你的专业背景、技术基础、常用工具、沟通偏好、输出格式偏好。对我来说,Codex 不需要每次都从零理解“我懂一点 Python、Stata、数据分析、金融和 AI 工具”,这些可以写成稳定背景。

第二类是系统原则。

比如什么工具负责什么,什么事情不能乱写,哪些信息需要确认后才能沉淀。原则越明确,AI 越不容易做“看起来很勤快、实际上很危险”的事。

第三类是当前上下文。

人每天的关注会变化。当前上下文不应该无限膨胀,而应该只记录这一段时间真正重要的 1-3 件事。否则 AI 读到的不是上下文,而是历史包袱。

第四类是长期记忆。

长期记忆要少而准。它应该记录稳定事实、明确决策和反复使用的术语,而不是把所有对话都吞进去。一个人如果把所有聊天记录都当成记忆,这不叫聪明,叫没有过滤器。AI 也是一样。

第五类是任务流程。

很多任务不是靠一句 prompt 就能稳定完成的。比如简历定制、博客撰写、读书整理、项目发布、笔记归档。这些任务都有自己的步骤、边界和检查点。与其每次重新讲,不如写成 skill。

这五类加起来,其实就是一个最小版的个人 AI 工作系统。

我现在怎么用它:简历和博客

讲系统结构很容易变成空话,所以我想用两个实际场景说明它对我有什么用。

简历定制

投递新岗位时,我经常需要根据 JD 调整简历。

如果只把这件事交给普通聊天窗口,它当然也能帮我润色。但问题在于:它不知道我的完整背景,不知道简历源文件在哪里,不知道哪些经历是真实可用的,不知道我过去的简历版本怎么写,也不知道最终应该输出到哪个文件夹。

my-codex-os 的作用,是让 Codex 先站在一个更稳定的位置上工作。

它可以读取我的关键记忆,知道我的教育背景、技能基础和常用表达;也可以通过工作区登记表找到简历文件夹,读取过去的简历内容;同时它知道简历相关文件的 source of truth 不在 my-codex-os,而在专门的简历工作区。

这样一来,我给它一个岗位描述,它就不是在孤立地“帮我写一份简历”,而是在我的真实材料边界内做定制:

  • 哪些经历应该更突出;
  • 哪些表述可以更贴近岗位;
  • 哪些内容需要压缩或展开;
  • 哪些能力不能凭空虚构;
  • 修改后的 Markdown、Word、PDF 应该回到哪里。

这里真正提升效率的,不只是 AI 会写,而是 AI 知道该基于什么写、写到什么程度、写完放回哪里。

博客文章撰写

另一个高频场景是博客。

我现在的博客不是只让 AI 随便代写,而是专门给它做了一个 blogverse-ops skill。这个 skill 会告诉 Codex:博客工作区在哪里,Hexo / Volantis 的目录结构是什么,哪些文件是源文件,哪些是生成文件,文章 frontmatter 应该怎么处理,发布前要怎么构建验证。

更有意思的是写作风格。

有一次我参考一个博主开源的“卡兹克风格创作 skill”,开始思考能不能给自己也做一个写作 skill。后来我把自己的写作样本、表达偏好、文章价值判断和常见问题整理进去,让 Codex 在帮我写博客时,不只是写得更顺,而是更接近我希望公开表达的方式。

这件事对我启发很大。

过去我们说 AI 写作,常常关注“它能不能写出一篇流畅文章”。但流畅只是最低要求。真正难的是:这篇文章有没有真实判断,有没有人的气息,有没有具体经验,有没有给读者带来启发。

所以我的写作 skill 里不只写了“语气要自然一点”,还会写:

  • 文章要从具体触发开始,不要从空泛口号开始;
  • 技术文章要讲清楚边界、代价和失败模式;
  • 观点要保留不确定性,不要装作无所不知;
  • AI 不能虚构我的一手经历;
  • 如果缺少真实材料,要标记出来让我补充;
  • 文章要有实用价值,也要有一点更深的思考。

换句话说,skill 不只是风格滤镜,更像是我把“什么叫一篇值得发的文章”写成了操作手册。

这大概也是 my-codex-os 最让我满意的地方:它让我把很多原本隐性的判断,变成了 AI 可以执行、可以复用、可以继续迭代的规则。

如果你也想搭一个,最小版本可以很简单

如果你读到这里,也想给自己搭一个类似系统,我不建议一上来就做复杂目录。

先建一个文件夹,然后写五个文件就够了:

1
2
3
4
5
6
my-ai-os/
├─ README.md
├─ PROFILE.md
├─ PROTOCOL.md
├─ CONTEXT.md
└─ SKILLS/

README.md 写这个文件夹是做什么的,以及 AI 启动时应该先读哪些文件。

PROFILE.md 写你是谁。不要写成自传,只写对协作有用的信息:背景、技能、偏好、常用工具、输出风格、重要边界。

PROTOCOL.md 写协作原则。比如哪些事可以直接做,哪些事必须先问;哪些工具负责计划,哪些地方负责保存知识;哪些文件不能乱改。

CONTEXT.md 写当前关注。保持短,只写当前真正重要的任务、约束和需要激活的记忆。

SKILLS/ 先从一个高频任务开始。比如:

1
2
3
SKILLS/
└─ resume-ops/
└─ SKILL.md

里面写清楚:

  • 什么时候触发这个 skill;
  • 需要先读哪些文件;
  • 任务怎么拆;
  • 哪些内容不能虚构;
  • 输出应该放在哪里;
  • 完成前要做什么检查。

不要急着追求自动化。先让 AI 能稳定读懂你的规则,已经很有价值。

我自己的经验是,个人 AI 系统不是一次性设计出来的,而是在高频任务里一点点长出来的。你每次发现“这句话我又解释了一遍”“这个边界 AI 又忘了”“这个流程以后肯定还会用”,就可以把它沉淀到系统里。

这有点像给未来的自己写说明书,只不过读者不是人,而是 AI。

便利的代价:当 AI 越懂你,隐私边界越重要

当然,这套东西不是没有代价。

一个 AI 越懂你,就越需要接触关于你的信息。你的背景、偏好、工作材料、写作样本、求职经历、项目文件、长期目标,甚至一些不适合公开的私人判断,都可能成为系统上下文的一部分。

这就会带来一个很现实的 trade-off:

为了便利,需要交出更多上下文;为了隐私,就要放弃一部分便利。

如果使用 OpenAI、Anthropic、Google 等大模型厂商的官方服务,你的信息至少会暴露给对应厂商的系统。即便厂商有隐私政策和数据保护机制,你仍然是在把上下文交给一个外部服务。

如果使用所谓“中转站”,风险会再多一层。你的请求不仅经过模型厂商,还会经过中转服务。中转站是否记录请求、如何保存日志、是否会滥用数据、是否真实调用它声称的模型,普通用户很难完全验证。

如果使用本地模型,隐私会好很多,但又会牺牲模型能力、部署成本、响应速度和工具生态。对普通用户来说,本地模型并不总是最省心的选择。

所以这里没有完美答案,只有取舍。

我的阶段性判断是:个人 AI 系统应该主动做隐私分层。

有些信息可以沉淀成长期记忆,比如公开背景、技术偏好、文章风格、常用工具;有些信息只适合留在本地文件里,不应轻易发给模型;还有些信息最好根本不要进入 AI 协作流程。

这也是为什么我不喜欢“把所有东西都喂给 AI”的说法。它听起来很强,但也很粗糙。一个可信的个人系统,不应该只追求让 AI 知道更多,还应该知道什么不该让它知道。

这个问题甚至可以放大到社会治理。

在个人 AI 助手里,我们为了更好的服务体验交出上下文;在更大的公共系统里,公民为了更高效的治理、更便捷的生活,也可能交出更多个人数据。便利和隐私之间的张力并不会因为技术进步而自动消失,反而会因为系统越来越强而变得更重要。

我不想在这篇文章里把话题展开成政治哲学论文,但至少对我来说,my-codex-os 提醒了我一件事:技术系统越贴近个人生活,边界意识就越不能缺席。

所谓让 AI 懂我,也是重新认识自己

写到最后,我觉得 my-codex-os 最有意思的地方,反而不完全是 AI。

因为当我试图让 AI 更懂我时,我必须先把自己说清楚。

我需要回答:

  • 我是谁;
  • 我现在真正关心什么;
  • 我希望别人怎么和我协作;
  • 我在哪些事情上要保守一点;
  • 我有哪些长期偏好;
  • 我有哪些反复出现的工作流程;
  • 我希望自己的文章是什么样;
  • 我愿意交出哪些信息,又想保护哪些边界。

这些问题看起来是在写给 Codex,其实也是写给我自己。

很多时候,我们以为自己很了解自己,但一旦要把这些东西写成 AI 可以执行的规则,就会发现许多偏好原来是模糊的,许多原则原来没有说清,许多工作流只是靠临时感觉在维持。

所以从这个意义上说,搭建个人 AI 系统也是一种自我整理。

它不是把人简化成一组配置文件,也不是让 AI 彻底替代自己的判断。更好的状态是:我把那些稳定、重复、可表达的部分交给系统,让 AI 在这些边界内帮我处理更多事务;而我把注意力留给更需要判断、选择和创造的部分。

my-codex-os 现在还很早期,也远远谈不上完美。它只是一个个人实验,一个不断修补的工作台,一个让我和 AI 协作时少一点重复解释、多一点稳定边界的文件夹。

但我越来越确信,这类系统会变得重要。

未来每个人可能都不只需要一个 AI 账号,而是需要一套属于自己的 AI 协作环境。它不一定复杂,不一定酷炫,也不一定非要叫 operating system。它也许只是一个文件夹,几份 Markdown,一些清楚的规则,几个稳定迭代的 skill。

但它背后的问题很值得认真对待:

当 AI 开始进入我们的工作、学习和创作现场时,我们要怎样把自己表达成一个可协作、可保护、可持续迭代的系统?

这就是我现在理解的 my-codex-os

它不只是给 Codex 使用的个人系统。它也是我在 AI 时代里,尝试重新认识自己、整理自己、保护自己,然后更好地借助工具的一种方式。

评论